Network-introduced delays are amongst the most important network performance metrics as they directly impact several wide area network applications ranging from real-time applications such as VoIP, interactive network gaming, to time-critical financial applications and localization systems.
Thus, monitoring the performance of data transmission delay within networks must involve a detailed understanding of how and where these delays are introduced.
Within traditional Time Division Multiplexing (TDM) technologies, network delay is predictable as per the deterministic transition time across TDM switches (e.g. in term of number of system clock transitions). However, with the tremendous increase in bandwidth demand, TDM is progressively replaced by Packet Switch Networks (PSNs) where packet jitters, also called as packet delay variations (random processes essentially induced by packet queuing), make packet resident time within the network node (called as network node resident time or transit delay from now on) unpredictable.
Accordingly, more than ever do PSN (Packet Switched Network) operators need methods for monitoring network delay (also known as network latency) in order to be able to take appropriate actions (e.g. network redesign/reconfiguration) aiming at respecting the Service Level Agreements (SLAs) and correcting SLA violations in term of network delay/latency.
To address these problems, Network operators generally rely on various end-to-end time-delay measurement tools such as                the PING command defined over the Internet Control Message Protocol (ICMPv4-RFC 792 and ICMPv6-RFC4443) which allows for measuring the end-to-end round-trip delay from a source to a destination host within an IP network;        the one-way delay measurement method described by RFC 2679. This method may require time synchronization depending on the network delay/latency value, on the required precision of the measurement and on the clock accuracy at both ends;        the traceroute (or TraceRT) command allowing to figure out the address of each network node (i.e. each network-layer device) along a network path from a source to a destination host. Traceroute also returns the end-to-end delays, respectively, from the source to each traversed node within the network path. These end-to-end delays are returned at the application level, meaning at the network protocol layer supporting the traceroute command.        
However, these tools return the whole end-to-end delay without any precision on the network node resident time (or latency). In other words, by using these tools, the returned delay value is a single unitary component, already including the network node resident time without any precision thereon.
The network-introduced delay may be broadly divided into:                network node resident time, comprising:                    the time needed by a network node to process (processing delay) a packet and prepare it for (re)transmission. The processing delay is mainly a function of the protocol stack complexity and of the computational power available (i.e. the available hardware) at each node and of the card driver (or interface card logic); and            the queuing delay, i.e. the total waiting time of packets within buffers of a network node before processing and/or transmission, which may depends on the details of the switching (or lower layer switches) of the network node                        the transit/link delay along network segments that link network nodes: the time needed to transmit an entire packet (from first bit to last bit) or more basically a single bit from the output port of a first network node to the input port of a second network node.        
Accordingly, knowing the whole end-to-end delay in a single value without giving any details on its components, up-to-date end-to-end delay measurement tools do not permit the operator to figure out the network segment(s) or the network node(s) where exactly corrective actions should be applied.
Thus, the main issue remains the collection of locally measured network nodes and network segments transit delays.
Yet another problem of the prior art is that it does not permit to determine what fractions represent residence time across network node or along network segment from the whole end-to-end delay.
A further problem is that known methods do not permit to obtain at once a distributed view of network nodes residence times, but end-to-end delays per network path taken separately.
One possible object of the present invention is to address the above-noted and other problems with the related art.
Another possible object of the present invention is to pinpoint where dominant delays are introduced within distributed network nodes.
Another possible object of the present invention is to provide a fine-grained composition of the network-introduced delays.
Another possible object of the present invention is the simultaneous determination of per-node latencies within a communication network.
Another possible object of the present invention is to provide a method and a system permitting to obtain a fine-grained distributed view of residence times per network node.
Another possible object of the present invention is to provide a method and a system permitting to obtain a fine-grained distributed view of residence times per delay-sensitive application.
Another possible object of the present invention is to split the end-to-end delay into components distinguishing the nodes resident times along a path from a source to a destination within an IP network.
Another possible object of the present invention is to allow operators to make rapid and precise diagnostic of the SLA violation issue (quality of the committed service not respected) in terms of network latency.
Another possible object of the present invention is to provide a diagnostic method that permits to accurately and simultaneously pinpoint network nodes that are sources of important (application) latencies.
Another possible object of the present invention is to uncover dominant network hops introducing the most latency and being responsible for delay degradation for a certain application.